【速報】Lambdaのパッケージフォーマットとしてコンテナイメージがサポートされるようになりました！！ #reinvent

LambdaのパッケージフォーマットとしてZIP形式に加えて、コンテナイメージがサポートされるようになりました！！

AWS re:Invent 2020

#AWS Lambda

#AWS

岩田智哉

2020.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CX事業本部@大阪の岩田です。

現在開催中のre:Invent 2020にてLambdaに関する新機能が発表されました。Lambdaのパッケージフォーマットとして、従来のZIP形式に加えてコンテナイメージがサポートされるという内容です！！

概要

Lambdaのパッケージフォーマットとして従来のZIP形式に加えて、コンテナイメージがサポートされるというアップデートです。ECRにPUSHされたコンテナイメージのURIをLambdaのCodeUriに指定することで、コンテナ化されたアプリケーションをLambda関数として実行できるようになりました。マネコンの表示も以下の通り更新されています。

後述しますが、全てのアプリケーションがそのまま動作するわけではなく、いくつか満たすべき要件があるため注意が必要です。詳細については公式ドキュメントもご参照ください。

Lambda requirements for container images

OCI準拠のコンテナイメージをサポート

コンテナイメージの形式としてはDocker Image Manifest V2 Schema 2もしくはOCI v1.0以上がサポートされます。AWS公式のベースイメージがDockerHubおよびECRから提供されるので、このベースイメージに開発したアプリケーションを追加してビルドするのが基本になりますが、前述のイメージフォーマットに準拠していれば、自分で1からビルドしたコンテナイメージを利用することも可能です。

コンテナイメージの要件

Lambda実行環境で正常動作させるためにコンテナイメージには以下の要件が要求されます。

LambdaのランタイムAPIと連携する

Lambdaのパッケージフォーマットとしてコンテナイメージを利用する場合、コンテナイメージはLambdaのランタイムAPIと連携して動作する必要があります。このランタイムAPIとの連携を容易にするため、AWSからAWS Lambda Runtime Interface Clients (RIC)というツールが提供されます。例えば開発者がAlpineをベースにした独自イメージを利用したい場合、イメージ内にRICを導入することでLambda関数としてデプロイ可能なコンテナイメージを簡単に作成できます。

AWS公式のベースイメージを利用する場合、ベースイメージには既にRICが内包されており、開発したアプリケーションをコンテナイメージに追加するだけで簡単にLambda用のコンテナイメージをビルド可能です。

RIC導入済みのベースイメージは以下のランタイム向けに提供されます

dotnetcore2.1
dotnetcore3.1
go1.x
java8
java8.al2
java11
nodejs12.x
nodejs10.x
python3.8
python3.7
python3.6
python2.7
ruby2.5
ruby2.7
provided
provided.al2

Read-Onlyなファイルシステムで動作する

Lambda実行環境は基本的にRead-Onlyです。書込み可能なのは/tmpディレクトリのみで、書込み可能なサイズは最大512MBに制限されています。

コード実行に必要な全てのファイルが読み取り可能なこと

Lambdaを実行するLinuxユーザーには必要最小限の権限のみ付与されています。アプリケーションが読み取りを制限されたファイルを参照していないことを事前に確認しておきましょう。

Linuxベースのコンテナイメージのみサポート

他のOSがベースのコンテナイメージはサポートされません。

サポートされないLambdaの機能

パッケージ形式としてコンテナイメージを選択した場合、以下の機能は利用できません、

Lambda Layers
- 複数のコンテナイメージで同じライブラリを利用したい場合、対象のライブラリを全てのコンテナイメージに導入しておく必要があります。
コード署名の検証

サポートされるコンテナイメージの設定

コンテナイメージでは以下の設定が利用可能です

ENTRYPOINT
CMD
ENV
WORKDIR

上記以外の設定、例えばEXPOSEやUSERといった設定はLambda実行環境では無視されます。

プログラミングモデルは変わらない

何かしらのイベントをトリガーにhandlerとして指定した処理が起動し、handlerにはイベントデータとコンテキストが渡されるというLambdaのプログラミングモデルは従来から変わりません。パッケージイメージとしてコンテナイメージを利用する場合、LambdaのhandlerはコンテナのENTRYPOINTとCMDで制御します。なお、ENTRYPOINTには前述のRICを指定して変更しないことが推奨されているようです。

ローカル環境でも簡単にテスト可能！！

コンテナイメージのサポートに伴い、AWS Lambda Runtime Interface Emulator (RIE)というツールの提供が開始されます。RIEはローカル環境で実行可能な軽量ウェブサーバーで、受け付けたHTTPリクエストをLambdaのイベントデータと同じJSON形式に変換する機能を持ちます。RIEを導入したコンテナイメージをビルドすることで、ローカル環境でも簡単にLambda用コンテナイメージのテストが可能です。

メリットやユースケース

パッケージ形式としてコンテナイメージを選択した場合、コンテナイメージのサイズ上限は10Gとなります。従来のZIP形式の上限250Mと比較して非常に大きなサイズとなっており、巨大なライブラリやモデルを利用するML系のワークローにおけるLambdaの利用範囲が広がりそうです。これまでも機械学習のモデルをEFSに配置するという選択肢がありましたが、EFSを利用する場合はVPCを意識する必要がありました。VPCを意識せずにサイズの大きなファイルを扱えるのは従来のZIPパッケージと比較して大きなメリットです。

またDocker CLIやDocker desktopといったOSSのコンテナ周辺ツールを利用できるのもポイントです。従来の資産を活用してLambdaベースのアプリケーションを構築、テスト、デプロイ、運用できるのも大きなメリットではないでしょうか？

気になるところ

パッケージフォーマットとして従来のZIP形式ではなくコンテナイメージを選択する場合、デプロイパイプラインではコンテナイメージのビルドとプッシュが必要になるため、ZIPに圧縮してS3にアップする従来のパッケージ処理と比較して所要時間が長くなることが予想されます。場合によってはLambda関数毎にコンテナイメージを作成するのではなく、1つのコンテナイメージを複数のLambda関数で使いまわしつつ、Lambda関数毎にCMDの指定を変えるというモノリスな構成が有効になるかもしれません。ただ、なんでもかんでも1つのコンテナイメージにまとめてしまうと、今度はLambda関数同士を疎結合に保てなくなるので、このあたりのバランス感はよく検討する必要がありそうです。